fix to not cancel Trust Bundle watch when another upstream is available #21867
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This fix the generated clusters for imported Peering upstreams in a specific scenario where there are multiple imported services on the same peer that have intentions to a single downstream service. In that specific scenario if one of the upstream services is removed from the list of services returned by the health endpoint while another is still available, this could result into the Trust Bundle watch being canceled.
The trust bundle watch is after used to create the relevant clusters associated with the healthy service in the down stream service and will result to those cluster not being generated (because we skip generation if the Trust Bundle is not available). In that case the following log is produced:
The situation will resolve it self next time the Trust Bundle watch is initialized and triggered but in the mean time this could result in a loss of connectivity from the downstream service to the upstream imported service.
Testing & Reproduction steps
Links
PR Checklist